Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1101

Internet Message Format | 1994-08-27 | 12.6 KB

Date: Thu, 28 Jul 1994 12:20:36 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Gem List
To: [e-mail]
In-Reply-To: <71940728015817/[e-mail]>
Message-Id: <Pine.3.87.9407281235.A14224-0100000@grad>
Mime-Version: 1.0
Precedence: bulk



On Wed, 27 Jul 1994, Daniel J. Hollis wrote:

> Subject:  GEM, etc.
>
> Whomever (again; I think this is the same one I answered too...):
> -----------------------------------------------------------------
> > Well, after much thought, I have decided to abandon the German
> > user-interface attitude of so overloading the interface with [sometimes
> > marginally useful] features that the program becomes unusable.
>
> Care to tell us *exactly* which 'marginally useful' features you mean?

Any features which make the display confusing, overload the user with too
many options to choose from, or simply wouldn't get used, yet it's included.

>
> > I see absolutely no point in going through all the trouble of adding
> > countless features and options, 90% of which will not be used in any
> > particular situation.  I want a window-library that makes my life easy
> > with documentation that takes me less than a week to read and understand,
> > well-commented, readable code, and simple bindings.
>
> Care to elaborate on *exactly* which "90%" will not be used? I hope you're
> not talking about stuff like dialogs in windows, background button
> activation, and listboxes. Those are *essential* to a good windowing library.
> Abandon those and you abandon any point in writing a library at all.

The Germans seems to have this tendancy toward making the user interface
as complicated as possible.  They will give the user too many options.
Perhaps 90% was an exageration... perhaps not.

>
> In terms of complexity, you can write a fully working GEM program that
> lets you put dialogs in windows, move them around, close them, iconify
> them, click buttons in background, etc. with only about 10 lines of code
> (using XAES).

You can with my library too.  I'm sure you can with any of our
libraries.  It makes sense to have all that built in.

>
> Simple bindings: #include <xaes.h>
>
> Difficult, eh?

Bindings:  the function calls you use and what parameters are passed.

>
> XAES's documentation includes lots of examples, something that lots of other
> libraries documentation fail to include. Maybe it's time they should start.
>

I am a technical writer and technical editor.  I am a fanatic about
making certain that documentation is good.  Mine will be good.

> > I see no point in absolutely abandoning the GEM style.  It makes sense to
> > make some modifications, yet some of the things you people are talking
> > about like sending key-presses to a background window are not only hard
> > to implement and counter-intuitive, but possibly DANGEROUS.  I will not
> > send keypresses to a background window, and unless it's absolutely
>
> Nobody should *ever* send keypresses to anything but the window under
> current focus. It is *incredibly* confusing to do otherwise. Just flip
> this option on in some X11 window manager and you'll learn really damn
> quick to hate it (as well as auto-window topping.. this is a totally
> STUPID idea!)

Some times it's OK once you get used to it, but not for GEM.

>
> By the way, I'm not sure what you mean by 'abandoning the GEM style'. There
> really is none! There is almost no consistency in GEM user interfaces,
> the way things work under different versions of TOS, etc.

I'm talking about abandoning the way GEM functions.  For example, the
closer should not pop up a menu (except in circumstances where it's
really useful, but let's not make a habbit of it).  This change in style
will do nothing but confuse and frustrate the user because he has to
contend with another dialog.

And too much stuff involving the background windows will also just be
confusing.

>
> I thought what we were trying to do here is establish *standards*, but if
> you're content on living with *no* standards, go right ahead.

I didn't say I wanted NO standards.  I want UNCONFUSING and SAFE
standards.  I'd think you'd have realized that by now.

>
> > necessary, I don't see any point in sending mouse-clicks to a background
> > window either.  It's just not GEM and it will only confuse and frustrate
> > people.
>
> Cop out. It's simple to do, a great convenience to the user as well. It
> will frustrate people more if they have to top every damn window just to
> use its gadgets, or if they have to induce hand cramps to drag a background
> window. If a user has more than 5 or 6 windows up, your interface will only
> get in the way and hamper the user, something a library should NEVER do.
>

I KNOW it's simple to do.  Even under normal TOS, my library already has
the option to do that... for the dialogs anyway.  I use it for tool boxes.

> > I see no point in screwing with GEM's top-window-had-focus method.  A
> > tool bar in a background window doesn't, as far as I'm concerned, have
> > focus when you click on it, so it's just fine with me.  I do not like
> > giving focus to anything other than the top window.  The X-windows method
> > is OK, but we're not using Xwindows... we're using GEM.  Don't forget that.
>
> Fine, be content living in 1985. The rest of the world will leave you behind,
> along with MS-DOS 3.3.

If living in 1985 lets me get more work done faster and easier, then so
be it.  I'm not one to hold back progress, but if this 'progress' is
radical to the point that it only makes things more confusing and harder
to work with, then I don't want it!

>
> > I want users to like my applications.  I want users to be able to use my
> > applications.  Therefore, I will give the user only what he needs to be
> > able to accomplish his task effectively.
>
> Sounds like you really mean 'programmer' here rather than 'user'.
> And if your interface is so primitive that no user will ever want to use
> it, what's the point? Nobody will want to use a library that is going to
> be too restrictive on the programmer and user.

Both, but the user is more important than the programmer in many cases.
If the user is happy, then the programmer makes money, even if it took
him an extra few hours.  I realise this could be used in support of the
app-defs file, but I have other reasons I don't like it.

>
> > With that, I have to ask what is in some of these other libraries that
> > take up over 200k?  Loads and loads of more features.... most of which
> > someone looking to get work done would never use.
>
> And that only get linked in if you use them. Some people don't seem to
> understand that even if a library is 400k, applications aren't necessarily
> going to be large. Only if you use things will they get linked in. It just
> means that with that particular library, you have more options to choose
> from -- a larger 'toolbox' so to speak.

Well, I break my library down into a few seperate .C files and the
programmer can pick which ones he wants.  I'm sure that's what most of us do.

>
> The test application for XAES that excercises the basic library functionality
> (dialogs in windows, iconifiable windows, background buttons, etc. etc.)
> only takes about 50k. That's for the full compiled application. That's not
> so big is it?

I don't know if it's big.  I don't know what it does.  Let me put it this
way... if mine does the same amount or more and it's smaller, than yours
it too big.  We'll see.

>
> > My library will continue to grow, but I doubt it will grow to more than
> > 50k, and I will always strive to make it simpler and simpler to use while
> > it gets more and more powerful.
>
> Kind of a contradiction here ;-) By limiting the size to 50k, you more or
> less limit what you can do with the library. At some point you will hit
> a brick wall.

I'm not LIMITING it to 50k.  Why don't you read it again?  I said, "...I
doubt it will grow to more than 50k...."  This means it probably won't,
but if it does, no biggie.  I'll have a good reason for it.  :)

>
> > ]No, you just convert the WF_TOPPED message to button clicks.  You
> > ]can't do drags and such under normal TOS from a background window, unless
> > ]you use the right button.
> > Am I not getting my point across?  I want to do drags in background
> > windows in normal TOS.  I KNOW how to convert WF_TOPPED messages into
> > button clicks.  I'm already doing it!  I want to do drags too.
>
> Ok, then use XAES. We allow you to drag/resize/scroll/close/etc windows in
> the background under normal TOS, even TOS 1.0.
>

How do you do this?  HOW?  You can't get anything other than WM_TOPPED
messages to background windows under normal TOS.

Oh, but you're replacing parts of AES, aren't you.  Vector-stealing.
Icky.  Isn't the exception stack frame different on the 68030 compared to
the 68000?

> > BTW, I'm using a Falcon 030.
>
> You could be using a 68040, what has this got to do with the discussion?

This wasn't directed at you.  It was directed at Evan.

>
> > ]As to where to put it, no one has even agreed to the above.  They are
> > ]still arguing about ^A and trying to vote on it.  Damn stupid to vote
> > ]on ^A when you can configure it instead.
> > It's not stupid.  For one thing, I do not like the config file.
>
> Because it requires a little effort to implement?
>

A LITTLE?  Are you kidding?  First I'm going to have to decode the file,
then I'm going to have to translate the codes into what gets displayed,
then I'm going to have to figure out where (and in what character space)
to put them into my menus, then I'm going to have to scan my list every
time the user presses a key, and on top of that, I'm probably going to
have to put up with some brain-dead method of figuring out which key is
which because someone wants to use hardware scancodes for the Ctrl-Letter
keys, which makes no sence because it's non-portable.

> > Secondly, if anyone uses Ctrl-A for select all, they're going to be in a
> > mess without a lot of hacking.  It's just TOO EASY to hit Ctrl-A, and I
> > don't want something as dangerous as Select-All assigned to it.  It's
> > perfectly logical.
>
> Instead of the programmer deciding what the user interface should be like,
> why not let the *USER* decide? (Gee, what a neat concept!) Duh!
>

Yeah, sure... and let's make the user spend 5 hours on install, 4 of
which is for configuration, and the last hour is for copying from floppy
all the code for all the features that the user turned off.

And then when the user wants to use the program, he has to deal with
XAES, your new user interface with all these new gadgets he's never seen
before, and spend hours just figuring out how to use the program, and
then when he wants to change a feature, he has to spend another hour
tracking it down from all the countless other options you have burried
somewhere.

KISS:  Keep It Simple, Stupid.

> > Something dangerously easy to hit like Ctrl-A should have something
> > totally harmess assigned to it like Redraw-window.
>
> Wow, ESC and RETURN are dangerously easy to hit, and their results could
> be even more devastating. Let's remove these keys altogether then.
>
> Why not let the user assume responsibility for their own actions?

Cute.  Very cute.  Ctrl-A is the only combination that I have ever hit
accidentally that also caused me catastrophic problems.  Unintentionally
selecting the whole document can cause anything from minor irritation to
lost data, depending on the rest of the user interface.

I am one of many people who have complained about Atari Works wiping out
their documents when their little finger slips and hits Ctrl and A at the
same time.  Take a good glance at any English keyboard and you will see
that the A is right next to Ctrl.  Now, if Ctrl-A did something
relatively harmess like redrawing the screen, moving the cursor to the
beginning of the line, pulling up a dialog for some purpose, etc, then I
would have no problem with it.  But to assign something as dangerous as
"Select-All" to it is pure lunacy!

RETURN and ESC generally do not cause people to lose files.  Ctrl-A has
many times.

You do NOT assign dangerous options to key combinations that are
FREQUENTLY accidentally hit.  I may be the only one on the GEM-List who
has this problem, but there are countless others who also have this
problem, and if the people on the GEM-List are so SHORT SIGHTED that they
cannot fathom that this might happen to someone, then I start to wonder
what other judgement errors they will make in the future, causing just as
much frustration for people and harm to their data.

Just because it doesn't happen to you, doesn't mean it doesn't happen to
you.  If you don't have astygmatism, does that mean that no one else does?